Terminal supervising device

ABSTRACT

A proxy server is used to provide various services managed by a plurality of dedicated servers to subscribers using terminals connected to a communication network. The proxy device has a three-tier type of architecture, with a stage for presenting services to terminals through the network, a service multiplexing stage communicating with the presentation stage, and a service access stage communicating with the multiplexing stage and including a plurality of access modules each associated with a respective dedicated server. The various services managed by the dedicated servers are multiplexed by the central stage which holds sessions with the subscribers without requiring a particular awareness of the services managed by the dedicated servers, nor of the physical features of the terminals.

This application is the US national phase of international applicationPCT/FR01/01339 filed 2 May 2001 which designated the US.

BACKGROUND OF THE INVENTION

The present invention relates to the field of company communications,and more especially to company communications systems offeringdiversified services, of multimedia type for example.

The development of company telecommunication has taken two routes:circuit switching telephony networks and packet switching computernetworks.

The architecture of private telephony networks has traditionally beenorganized around a switching system comprising one or more automaticexchanges or PABX (“Private Automatic Branch eXchange”) connected to acollection of telephone terminals. The deployment of telephone servicesis implemented by means of signaling information exchanged between acall server, made up of one or more entities of the switching system,the PABX or PABXs and the telephone terminals. A family of communicationprotocols generally supporting several telephony services is necessaryfor establishing such exchanges. The ISDN (“Integrated Services DigitalNetwork”) protocols provide such an example of a family of protocols.

The development of new services has led to the incorporation ofadditional servers into communication systems, these servers beingdedicated to these new services (for example voice messaging server,directory server, etc.). The signaling protocols initially designed forcall processing functions, for example the H.323 protocol standardizedby the International Telecommunications Union, have naturally evolvedtoward integration of new services.

Other signaling protocols, specific to particular services have beendeveloped, such as for example the DAP (“Directory Access Protocol”) andLDAP (“Lightweight Directory Access Protocol”) protocols specific to thedirectory services, the SMTP (“Simple Mail Transfer Protocol”) and IMAP(“Internet Message Access Protocol”) protocols specific to messaging, orthe HTTP (“HyperText Transfer Protocol”) protocol specific to webbrowsing, etc. These protocols are customarily used only for thedeployment of the corresponding services within data transmissioncomputer networks. Their interoperation with telephony type signalingprotocols requires that servers of different kind should be capable ofcommunicating with one another, that is to say that some at least of theservers should be aware of the “jobs” of the other servers. This resultsin great complexity of the protocols as well as a lack of flexibilitywhen one wishes to upgrade the functions offered.

Moreover, the use of multiple servers dedicated to different jobs oftenleads the subscribers to carry on a dialog successively with severalservers to accomplish a given function, thereby affecting the efficiencyand ergonomics of the system.

Within the framework of the web service, it is known to process userrequests by interrogating heterogeneous information sources, totranslate the various responses and to group them into a data page of atagging language such as HTML (“HyerText Markup Language”) or XML(“eXtended Markup Language”), which is returned to the user's webbrowser software. This can be carried out by means of architectures ofthe three-tier type, as described in the article by C. Petrou et al. “AnXML-based, 3-tier Scheme for Integrating Heterogeneous InformationSources to the WWW”, Proc. of the IEEE 10^(th) International Workshop onDatabase and Expert Systems Applications, 1999, pages 706-710. Thismakes it possible to process user requests individually, but not topresent thereto diversified services to which same has access.

A primary object of the invention is to make the architectures ofcommunication networks more flexible, in the sense that they readilyallow the integration of new services or the modification of existingservices, by circumventing the specific nature of the interfaces withthe servers of various jobs while offering the subscribers considerablefunctional richness.

SUMMARY OF THE INVENTION

The invention thus proposes a device for supervising terminals which toa communication network for supplying subscribers using the terminalswith various services managed by a plurality of dedicated servers, thedevice comprising means of interfacing with the network, a stage forpresenting services to the terminals through said interfacing means, aservice multiplexing stage communicating with the presentation stage,and a service access stage communicating with the multiplexing stage andcomprising a plurality of access modules each associated with arespective dedicated server. Each access module is arranged to delivertagged data pages to the multiplexing stage in response to incomingmessages from the associated dedicated server and/or to page requestsfrom the multiplexing stage, and to deliver merge data to themultiplexing stage in response to merge requests, each delivered pagebeing associated with a subscriber with which the multiplexing stage hasa communication session in progress through the presentation stage,whereby some at least of the pages delivered to the multiplexing stagecontain merge codes pertaining to services. The multiplexing stagecomprises means for processing each page received from the access stageso as to detect the merge codes, address a merge request to the accessmodule associated with the dedicated server managing the service towhich each detected merge code pertains, substitute the merge datadelivered by said access module in response to the merge request for afield of the page including the detected merge code, and supply theprocessed page to the presentation stage within the framework of thesession in progress with the associated subscriber. Each page suppliedto the presentation stage contains tagged data describing, according toa format independent of the terminals, elements of interaction with theassociated subscriber. The presentation stage comprises terminal controlmeans for interpreting each page received from the multiplexing stagewithin the framework of a session in progress with a subscriber usingone of the terminals so as to generate commands adapted to thepresentation on the terminal of interaction elements described by thetagged data of the page. The multiplexing stage further comprisesrouting means for receiving page addresses from the presentation stagewithin the framework of a session in progress with a subscriber,identifying an access module for which the page address received isintended and transmitting a corresponding page request to the identifiedaccess module.

The device has a three-tier type of architecture, and acts as a “proxy”agent in relation to the terminals for the various services managed bythe dedicated servers. These services are multiplexed by the centralstage which holds sessions with subscribers without having anyparticular awareness with regard to the services managed by thededicated servers or with regard to the physical features of theterminals.

The multiplexing stage combines elements pertaining to various jobs inthe data which are supplied for the presentation of the services to thesubscribers. To do this, it simply associates determined merge codeswith access modules to which it addresses the requests making itpossible to supplement the pages previously received. It is these accessmodules which, in a stand alone manner or in conjunction with associateddedicated servers, incorporate an awareness of the corresponding jobs tosupply the data required by the multiplexing stage.

It is therefore relatively easy to enhance or upgrade the system. Theaddition or the substitution of new dedicated servers functioningaccording to specific protocols does not involve any reassessment of theprotocols used elsewhere in the system.

In a preferred embodiment of the device, the tagged data contained insome at least of the pages supplied to the presentation stage describe,in addition to the elements of interaction with the associatedsubscriber, at least one link between one of said interaction elementsand a page address. The terminal control means of the presentation stageare then arranged to associate each link of a page received from themultiplexing stage within the framework of a session in progress with asubscriber using one of the terminals with an event which may occur atthe terminal, and to return the page address of said link to themultiplexing stage within the framework of said session in response toan occurrence of said event.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram illustrating an exemplary telecommunication networkintegrating a device according to the invention;

FIG. 2 is a general diagram of a device according to the invention;

FIG. 3 is a schematic diagram of a module of the access stage of thedevice;

FIG. 4 is a schematic diagram of the multiplexing stage of the device;

FIG. 5 shows an exemplary template displayable on a terminal connectedto the network.

DESCRIPTION OF PREFERRED EMBODIMENTS

In the exemplary embodiment described hereinbelow, terminal equipment ofdifferent types have access, through a company communication network andof a device according to the invention, to the following diversifiedservices: telephony, logging of calls, directory, unified messaging(i.e. voice or electronic messaging), web browsing on an Internet orIntranet network, these services being provided by a collection ofdedicated servers connected to the network.

FIG. 1 shows the terminals of various types (for example mobile set 100,microcomputer 101, ISDN set fitted with an IP adapter 102, IP native set103) which are linked to a packet mode communication network 300operating according to the IP (“Internal Protocol”) protocol. Thenetwork 300 can be a local area network (LAN) with which an organizationis equipped so as to supply services for transmitting data to the usersof the terminals 100-103. It consists for example of a plurality ofsubnetworks of Ethernet type between which the switching of the IPpackets is performed in a conventional manner by routers (notrepresented).

Several servers, dedicated to the relevant services, are furtherconnected to the LAN 300: a telephony server 200, a directory server201, a unified messaging server 202, a web browser server 203, as wellas a server for logging telephone calls 204.

A device according to the invention 400, a so-called “proxy server”, isalso linked to the LAN 300. This device fulfills a proxy function, thatis to say that, to access the services managed by the dedicated servers200-204 of the network 300, the terminals 100-103 can open a sessiononly with the device 400. Moreover, the incoming signaling relating tothese services can be addressed to the terminals only through the device400.

Of course, it is possible for some of the servers 200-204, 400 to beembodied within a common platform. For example, the telephony andlogging servers 200, 204 will frequently be in the same item of networkequipment. The proxy server 400 may also be in the same item ofequipment as one of the dedicated servers, for example the telephonyserver 200.

The proxy server 400 has an architecture of three-tier type, of whichFIG. 2 shows the three stages: service access stage 410, servicemultiplexing stage 420 and service presentation stage 430.

The access stage 410 (job entity) groups together all the processingspecific to the various services managed by the dedicated servers200-204. It effects the interfacing of the proxy server 400 with thevarious dedicated servers 200-204, and exchanges data originating fromand destined for the service entity 420 according to a unified format.

The stage 410 comprises access modules 4100-4104 respectively associatedwith the dedicated servers 200-204 with which they are capable ofcarrying on a dialog. Each access module 4100-4104 performs theprocessing relating to the supplying of a service by the associateddedicated server 200-204 to the users of the network integrating theproxy server 400. Thus is found, in the example considered, an accessmodule 4100 associated with the dedicated telephony server 200, anaccess module 4101 associated with the dedicated directory server 201,an access module 4102 associated with the dedicated messaging server202, an access module 4103 associated with the dedicated browsing server203 and an access module 4104 associated with the dedicated server forlogging calls 204.

In an embodiment of the invention, each access module 4100-4104 managesa connection to the application level of the OSI model with itsassociated dedicated server 200-204. The structure of the data exchangedand the exchange protocol for these data depend on the service concerned(for example H.323 for telephony, LDAP for the directory service, IMAP4for electronic messaging, HTTP for browsing, etc.).

In another embodiment, some or all of the dedicated servers 200-204 talkdirectly to the corresponding access modules 4100-4104 according to aconnection of a transport level protocol, typically TCP (“TransmissionControl Protocol”), and exchange tagged data pages supplying semanticdescriptions of elements according to the XML language (“eXtended MarkupLanguage”). Versions of XML, whose document type descriptions (DTD) havebeen developed for adaptation to various jobs, can thus be used for theexchanges between the proxy server 400 and the servers of thecorresponding jobs.

The multiplexing stage 420 (service entity) carries out the interactionbetween the various services managed by the dedicated servers 200-204,routes the requests originating from the presentation stage 430 towardthe modules of the access stage 410, and sends the data originating fromthe access stage 410 to the presentation stage. It moreover administersthe sessions opened with the various terminals managed by the proxyserver 400. The processing performed by the stage 420 does not allow forany awareness of the services whose information it relays, or of thecharacteristics of the terminals connected to the network 300.

The presentation stage 430 (presentation entity) contains the collectionof means of connection and of dialog with the various types of terminalscompatible with the proxy server 400, and fulfills the function ofpresenting the data received from the multiplexing stage 420 to theterminal from which the subscriber who is the recipient of the data hasopened a session with the proxy server 400. According to theircharacteristics, the terminals 100-103 can be arranged to communicateaccording to various types of communication protocols. For each of theseprotocols, the presentation stage 430 comprises an interface module 431,432 which organizes the transmission and reception of the correspondingmessages.

The access modules 4100-4104 and the terminal interfacing modules 431,432 of the presentation stage are connected to a module 440 forinterfacing with the LAN 300 which accomplishes the functions of layers1 to 4 of the OSI model. In the example considered, the module 440manages the exchanges of the proxy server 400 according to the TCP, IPand Ethernet protocols. Of course, if the proxy server 400 isincorporated into the same item of equipment as one of the dedicatedservers 200-204, the corresponding access module will be able to talkdirectly to this dedicated server without going through the interfacemodule 440.

The access stage 410 generates tagged data pages, i.e. collections ofdescriptions of elements whose syntax is common to the collection ofaccess modules 4100-4104, which it sends to the multiplexing stage. In apreferred embodiment of the invention, data description pages structuredin the XML sense are used. Alternatively, it would be possible to useobjects of COM type (“Component Object Model”) as proposed by theMicrosoft corporation. The benefit of such pages resides in theirflexibility of use, and the possibility of presenting data in a formatwhich can be adapted through a simple filtering operation to any type ofterminal.

The XML pages delivered by the access stage 410 form the subject of aprocessing in the multiplexing stage 420, which will be described later,before being sent to the presentation stage 430. The processed XML pagessent to the presentation stage 430 contain tagged data which describe,according to a format independent of the terminals, elements ofinteraction with the subscribers. Some of these elements of interactionare to be presented dynamically to the subscriber to whom the page isrelevant, the mode of presentation being defined in the stage 430 as afunction of the type of man/machine interface with which the terminalused is provided (on-screen display of such type or such size, soundsignaling, voice messages, etc.) and possibly of subscriber-definedparameters for configuring the man/machine interface.

These elements presented dynamically may represent a subscriber context(for example incoming call, busy terminal, message received, etc.), acontext of the information supplied within the framework of a service(for example directory number, content of a message, web page, etc.), acontext of the entry fields allowing the subscriber to input informationuseful to the servers (for example call number, identification ofdirectory record, message to be transmitted, etc.), or a context of theactions which the subscriber can select with the aid of an eventprogrammable in the presentation stage (actuation of a virtual button,voice command, etc.). For this latter type of element, the tagged dataof the XML page belong to a dynamic link which points to a page address.

Other interaction elements described in the XML pages sent to thepresentation stage 430 may pertain to determined events liable to occurat the terminals and defined in a static manner, i.e. independently ofthe subscriber contacts and of the dynamic elements presented. Theseevents, defined at the level of the presentation stage 430, comprise forexample the actuation by the subscriber of a special button, the expiryof a time-out, etc. The tagged data of the XML page describing this kindof element belong to a static link pointing to a page address.

In the aforesaid links, it is possible to use page addresses similar toURL addresses (“Uniform Resource Locator”) commonly used in browsingapplications, for example of the form “process_id://page_id”, where thefield “process_id” designates a process pertaining to an access module4100-4104, and the field “page_id” designates a page managed by saidprocess. Certain addresses are supplemented with one or more fields forparameters useful for the production of the designated page, thecorresponding parameters being suppliable explicitly in the XML pagesent to the presentation stage 430 or recoverable from the entry fieldsdescribed in this XML page.

FIG. 2 shows that the presentation stage 430 comprises an XML browser433 which analyses the pages received from the multiplexing stage 420 inconjunction with a memory 434 containing the DTD defining the commonsyntax of the pages. The browser 433 extracts the dynamic elements ofeach page received for a subscriber, and supplies them to the module435, 436, 437 for controlling the man/machine interface of the terminalused by the subscriber. Several control modules 435-437 are provided inthe stage 430 for catering for the various types of MMI with which theterminals may be equipped. These modules 435-437 manage the appropriatecommands for the presentation of the elements required on the terminals,which commands are delivered by way of the interface modules 431, 432and 440. The control modules 435-437 further monitor the occurrence ofthe events corresponding to the action links defined in the HML page,and advise the browser 433 of the detection of such an event. Inresponse to the detection of such an event, the browser 433 returns tothe multiplexing stage, within the framework of the session in progresswith the subscriber concerned, a primitive GET_URL which includes thepage address of the corresponding link.

FIG. 3 diagrammatically shows the components of a module 410 x of theservice access stage 410 of the proxy server 400. A translation unit 411carries out the interfacing with the dedicated server 20 x correspondingto the relevant access module 410 x. The unit 411 manages in particularthe entire dialog with the dedicated server, and transcribes the datareceived from the server into a uniform format corresponding to thepages exchanged within the proxy server 400. To do this, it is furnishedwith a translation table 412 which allows it to associate, with the dataexchanged according to a specific format with the dedicated server, tagscommon to all the modules of the proxy server 400. Once translated, thedata received are sent either to a unit for constructing dynamic pages413 or to another unit 414 of the module 410 x, this other unit beingcalled the merge data server.

The unit for constructing dynamic pages 413 organizes the data taggedwithin an XML page according to the common structure defined in the DTD415. The page thus constructed is sent to a unit 416 called the pageserver which associates it with information identifying the subscriberfor which it has been constructed.

Two types of message may trigger the dispatching of an XML page from theaccess module 410 x to the multiplexing stage:

-   -   a message originating from the associated server 20 x destined        for an identified subscriber. In this case, the unit 413        constructs the page to be transmitted from the elements        contained in the incoming signaling message, in accordance with        the common structure defined in the DTD 415;    -   a page request received from the multiplexing stage for an        identified subscriber. On receipt of a page request, the page        server 416 firstly determines whether the page requested is a        static page contained in the page library 417. If so, it is not        necessary to interrogate the dedicated server: the page server        416 constructs the page on the basis of the static page stored        and of any parameters which may have been supplied with the        request, then addresses the page thus obtained to the        multiplexing stage 420 by indicating the subscriber concerned.        Otherwise, the page is constructed by the unit 413 which        interrogates the dedicated server 20 x through the translation        unit 411 when external data are required to construct the page.        The unit 413 can also extract, from the page requests and/or        from the data of the page in construction, events or parameters        which are sent to the translation unit 411 to convey the        signaling back up to the dedicated server 20 x.

The access module 410 x can moreover receive from the multiplexing stage420 merge requests which are processed by the merge data server 414. Amerge request comprises a merge code associated with a merge data type,and possibly associated parameters. The servers 416 and 414 operate in asimilar manner, the server 414 manipulating, however, merge data whichare not generally organized in the form of pages. On receipt of a mergerequest, the server 414 firstly determines whether the data requestedare static data contained in the library 418. If so, it is not necessaryto interrogate the dedicated server: the server 414 fetches the mergedata from the library 418, supplements them with any parameters whichmay have been supplied with the request, then returns them to themultiplexing stage 420 by indicating the subscriber concerned.Otherwise, the merge data server 414 interrogates the dedicated server20 x through the translation unit 411, by indicating any parameterswhich may be supplied with the request, to obtain the external datarequired and to return the merge data which result therefrom to themultiplexing stage 420.

The merge codes are present in some of the pages returned by the pageservers 416 of the access modules 4100-4104. They are generallyaccompanied by parameters serving to formulate the merge data. Tofacilitate their identification in the XML pages, they can comprise aspecial tag and a function name making it possible to identify a logicport of the access stage 410 for the routing of the corresponding mergerequest (this name is associated with one of the access modules4100-4104 and with a logic port of the latter to which the correspondingmerge request must be dispatched). Their syntax is for example thefollowing: “%function(para1, . . . , paraN)”, where “%” is thecharacteristic tag of the merge codes “function” is the function name,and para1, . . . , paraN designate the N associated parameters (N≧0).Some of these associated parameters may themselves be merge codes, thebrackets making it possible to separate the merge codes nested accordingto a tree structure.

FIG. 4 diagrammatically shows the components of the servicesmultiplexing stage 420 of the proxy server 400. Each page received fromthe access stage 410 is analyzed by an analysis and merge engine 421.The merge operation consists in replacing the merge codes, present inassociation with any parameters in a page received from an access module4100-4104, with merge data consisting of tagged data or a link.

This merge operation requires no awareness of the organization of theservices in question at the level of the multiplexing stage 420. Themerge codes may be flagged without performing any detailed parsing bysimply detecting the tags “%” which may be present in the page received.When the analysis engine 421 thus flags a merge code, it interrogates alookup table 422 on the basis of the function name of the code, therebyenabling it to identify the logic port of the access stage 410 to whichthe merge request should be routed. The latter can be formulated verysimply by copying the merge code with its parameters and by identifyingthe subscriber concerned. On receipt of the merge data returned for thissubscriber by the merge data server 414 of the interrogated accessmodule, the analysis and merge engine 421 substitutes them for the mergecode previously located.

The correspondences (merge code function name, logic port of the accessstage) are recorded in the table 422 during a procedure for installingthe access modules 4100-4104, in which the latter declare to themultiplexing stage 420 the function names of the merge codes processedby their respective merge data serves 414 by indicating the associatedlogic ports. If a detected merge code does not appear in the lookuptable 422, the analysis and merge engine 421 simply deletes this codefrom the XML page processed.

In the same setup procedure, the access modules 4100-4104 declare to themultiplexing stage 420 the identities “process_id” of the processestaken into account by their respective page servers 416 by indicatingthe associated logic ports. This allows the multiplexing stage 420 torecord the matching of these identities “process_id” with these logicports in another table 423.

The multiplexing stage 420 comprises a routing module 424 which receivesthe addresses of pages received from the presentation stage 430 with theprimitives GET_URL pursuant to events detected at the level of theterminals. The routing module 424 queries the lookup table 423 on thebasis of the identities “process_id” contained in these addresses todetermine the logic port of the access stage 410 where the page requestis to be routed, and it sends this request accompanied by thecorresponding parameters.

Each creation of association of a (physical terminal, subscriber) pairby the presentation stage 430 gives rise to a subscriber session openingrequest received by a subscriber management module 425 of themultiplexing stage 420 (OPEN_SESSION primitive). This module 425operates with a subscriber registration table 426 for the subscribershaving an open session. The subscriber session opening request containsinformation indicating among other things a subscriber identifier (forexample his telephone call number) and a logic port of the presentationstage for the dispatching of the pages destined for the subscriber. Itmoreover contains subscriber authentication information, such as forexample a password entered by the subscriber. The module 425interrogates the table 426 to ensure that the subscriber is not alreadyregistered there, in which case it returns a negative acknowledgementNACK which is sent to the presentation stage 430. Otherwise, it createsa record in the table 426 including the information contained in thesession opening request, then sends back a positive acknowledgement ACKdestined for the presentation entity 403. A mechanism for deleting arecord is also provided, for example, in the case of a dissolution of a(terminal, subscriber) pair which gives rise to the dispatching by thepresentation stage of a subscriber session closure request destined forthe module 425 (CLOSE_SESSION primitive).

The receipt of a positive acknowledgement ACK by the presentation stage430 triggers a default home page request to the multiplexing stage 420.This request can be formulated in the form of the address of the pagerequested accompanied by parameters corresponding to the subscriber(subscriber number, password) and to the parameters for addressing itsterminal on the LAN for the routing of voice and data (networkparameters such as IP address, UDP port numbers, etc.), and relayed likethe other page addresses by the routing module 424 to the access stage410.

This default home page may in particular be generated by the accessmodule 4100 associated with the telephony server 200. It may describe ahome template offering for example the various services offered by theconnected dedicated servers 200-204, and apprising the subscriber of hiscurrent telephone context. The information (links) relating to theservices available contain in particular page addresses intended to besent by the access modules 4100-4104 on request from the service. Thus,when the subscriber selects for example the telephony service, thepresentation stage 430 sends the page address contained in the selectedlink to the multiplexing stage 420, within the framework of the sessionopen with the subscriber. Aware of this session, the subscribermanagement module 425 can inform the routing module 424 so that the pagerequest is sent to the access module 4100 by indicating the identity ofthe subscriber, the logic port having been obtained in the table 423.

The subscriber management module 425 and the routing module 424intervene in the same way for the various requests for pages emanatingfrom the presentation stage.

Thus, the processing of these requests by the multiplexing stage 420requires no awareness of the service relevant to the request. Therouting module 424 merely invokes a logic port by passing as argumentsthe information contained in the address data received from thepresentation stage as well as the identification of the subscriber,without analyzing the content of the request or the identity of theservice which processes it. Once the request has reached the module4100-4104 of the access stage 410, it is served as explainedhereinabove, this giving rise to the dispatching by this access moduleof a new XML page accompanied by the subscriber's identificationinformation. This XML page is received by the analysis and merge engine421 which analyzes it and effects the merges required as the case maybe, as indicated previously.

The subscriber's management module 425 also co-operates with theanalysis and merge module 421 to route the pages processed within theframework of the sessions open with the various subscribers. The module425 queries the table 426 to determine from the subscriberidentification information accompanying each XML page the logic portcorresponding to the session in progress with the subscriber, to whichit routes the page processed (SEND_PAGE primitive).

By way of example, an XML page generated by the access module 4101associated with the directory server 201 can include tagged data suchas:

-   -   $label/name=DUPONT    -   $label/firstname=PAUL    -   $label/phonenumber=78778    -   $label/mailaddress=DUPONT@MATRANORTEL    -   %call(78778, MakeCall)    -   %mail(DUPONT@MATRANORTEL, SendMail).

In this example, the first four lines describe elements to be presentedto the subscriber, which are delimited by the tag “$label”, namely thename of a subscriber listed in the directory (Dupont), his first name(Paul), his telephone number (78778) and his messaging address(dupont@matranortel). The presentation stage will adopt the mode ofdisplay of these elements which is suitable for the terminal used by thesubscriber. The last two lines comprise merge codes delimited by the tag“%”. The code “%call(78778, MakeCall)” detected by the analysis andmerge engine 421 brings about a merge request to the access module 4100associated with the telephony server, which responds thereto for exampleby returning the merge data:

-   <link    href=“cs_server://1049600?phonenumber=78778”title=$label/MakeCall”>,    which represent a link between the tagged data item    “$label/MakeCall”, which will generate the presentation to the    subscriber of a call command (virtual button) and the page address    “cs_server://1049600” which corresponds to a telephone call page    managed by the access module 4100 associated with the telephony    server 200, where the call parameter “phonenumber=78778” designates    the number called. Likewise, the code “%mail (DUPONT@MATRANORTEL,    SendMail)” detected by the analysis and merge engine 421 brings    about a merge request to the access module 4102 associated with the    messaging server, which responds thereto for example by returning    the merge data:-   <link    href=“mail_server://1249600?mailaddress=DUPONT@MATRANORTEL”title=$label/SendMail”>,    which represent a link between the tagged data item    “$label/SendMail”, which will generate the presentation to the    subscriber of a message dispatch command (virtual button) and the    page address “mail_server://1249600” which corresponds to a message    dispatch page managed by the access module 4102 associated with the    messaging server 202, where the parameter    “mailaddress=DUPONT@MATRANORTEL” designates the dispatch address for    the message.

FIG. 5 is an illustration of an exemplary display generated on thescreen of a terminal pursuant to the production of the previous page,processed by the analysis and merge engine 421. The activation by thesubscriber of one of the virtual buttons T will then trigger theconveying of the page address “cs_server://1049600” or“mail_server://1249600” back up from the presentation stage 430 to themultiplexing stage 420, then a page request to the access module 4100 or4102 to initialize the establishment of the requested call or thedispatching of the message.

The merge operation can involve several successive merge requests whennested merge codes are present in the page. In this case, the hierarchyof the brackets allows the analysis engine 421 to separate the mergecodes and to begin by generating the merge requests for the inner codes,the intermediate merge data then consisting of parameters which theanalysis and merge engine 421 substitutes for the corresponding mergecodes.

By way of example, an XML page generated by the access stage 410 caninclude the following merge code:

-   -   %call(%last_outgoing_call, Bis).

In this example, the merge code “%last_outgoing_call”, processed first,corresponds to a logic port of the merge data server 414 of the accessmodule 4104 associated with the logging server. On receipt of the mergerequest addressed to this logic port, the access module 4104interrogates the logging server 204 to fetch the last telephone numbercalled by the subscriber, and this number is returned to themultiplexing stage by way of merge data, for example “78722”. The mergecode “%call (78722, Bis)” resulting from this first step is thenprocessed in turn by means of a merge request to the access module 4100which returns, in the same way as in the previous example, the taggeddata:

-   <link    href=“cs_server://1049600?phonenumber=78722”title=%label/Bis”>,    making it possible to present the subscriber with a virtual button    corresponding to the function for repeating the last call (bis    button).

It may be seen that the engine 421 allows the multiplexing stage 420 tomerge objects corresponding to different services without having apriori awareness of the services concerned. Thus, a page received fromthe stage 410 originating from a first access module and containing anaction corresponding to a service whose processing takes place within asecond access module is processed by the multiplexing stage 420 in sucha way that it no longer contains any merge codes, but links and/ortagged data describing elements to be presented, and that it can beutilized by the presentation stage 430 without there being any need toestablish dialog between the various servers 200-204 or access modules4100-4104.

Neither does the incorporation of the merge codes into the XML pagesdelivered by the access stage imply that an access module is aware ofthe structure of the services offered by the dedicated servers withwhich it is not associated. In the first example above, to insert thecodes “%call (78778, MakeCall)” and “%mail(DUPONT@MATRANORTEL,SendMail)”, the page server 416 of the access module 4101 associatedwith the directory server 201 simply needs to known that “78778” is acallable telephone number and “DUPONT@MATRANORTEL” a messaging address(this forming part of the directory job), without being aware of how theservers 200 and 202 process the telephone calls and the dispatching ofthe messages.

1. A device for supervising terminals connected to a communicationnetwork for supplying subscribers using the terminals with variousservices managed by a plurality of dedicated servers, the devicecomprising means of interfacing with the network, a stage for presentingservices to the terminals through said interfacing means, a servicemultiplexing stage communicating with the presentation stage, and aservice access stage communicating with the multiplexing stage andcomprising a plurality of access modules each associated with arespective dedicated server, wherein each access module is arranged todeliver tagged data pages to the multiplexing stage in response toincoming messages from the associated dedicated server and/or to pagerequests from the multiplexing stage, and to deliver merge data to themultiplexing stage in response to merge requests, each delivered pagebeing associated with a subscriber with which the multiplexing stage hasa communication session in progress through the presentation stage, someat least of the delivered pages to the multiplexing stage containingmerge codes pertaining to services, wherein the multiplexing stagecomprises means for processing each page received from the access stageto detect the merge codes, address a merge request to the access moduleassociated with the dedicated server managing the service to which eachdetected merge code pertains, substitute the merge data delivered bysaid access module in response to the merge request for a field of thepage including the detected merge code, and supply the processed page tothe presentation stage within a framework of the session in progresswith the associated subscriber, each page supplied to the presentationstage containing tagged data describing, according to a formatindependent of the terminals, elements of interaction with theassociated subscriber, wherein the presentation stage comprises terminalcontrol means for interpreting each page received from the multiplexingstage within the framework of the session in progress with thesubscriber using one of the terminals to generate commands to thepresentation on the terminal of interaction elements described by thetagged data of the page, and wherein the multiplexing stage furthercomprises routing means for receiving page addresses from thepresentation stage within the framework of the session in progress withthe subscriber, identifying the access module for which the page addressreceived is intended and transmitting a corresponding page request tothe identified access module.
 2. The device as claimed in claim 1,wherein the tagged data contained in some at least of the pages suppliedto the presentation stage describe, in addition to the elements ofinteraction with the associated subscriber, at least one link betweenone of said interaction elements and a page address, and wherein theterminal control means of the presentation stage are arranged toassociate each link of a page received from the multiplexing stagewithin the framework of the session in progress with the subscriberusing one of the terminals with an event which may occur at theterminal, and to return the page address of said link to themultiplexing stage within the framework of said session in response toan occurrence of said event.
 3. The device as claimed in claim 2,wherein the links described in the tagged data contained in the pagessupplied to the presentation stage comprise static links which thecontrol means associate with predetermined events which can occur at theterminals and dynamic links associated with elements presenteddynamically at the terminals.
 4. The device as claimed in claim 2,further comprising means for generating a home page on completion of anopening of session between the multiplexing stage and the subscriberusing one of the terminals, the home page being processed by thepresentation stage and contains links with page addresses intended forvarious modules of the access stage.
 5. The device as claimed in claim4, wherein the home page generation means are included in one of theaccess modules.
 6. The device as claimed in claim 1, wherein said taggeddata pages are XML pages established according to a format common to thewhole device.
 7. The device as claimed in claim 1, wherein themultiplexing stage comprises subscriber management means co-operatingwith a memory where data pertaining to the subscribers is stored.
 8. Thedevice as claimed in claim 7, wherein the data pertaining to thesubscriber which are stored in said memory comprise a subscriberidentifier and authentication parameters, which the subscribermanagement means compare with parameters supplied by the subscriber uponan opening of session with said subscriber.
 9. The device as claimed inclaim 1, wherein the routing means of the multiplexing stage co-operatewith a memory containing a lookup table for matching portions of thepage addresses received from the presentation stage with respectivelogic ports of the access stage associated with the access modules towhich the corresponding page requests are to be sent.
 10. The devipe asclaimed in claim 1, wherein the processing means of the multiplexingstage co-operate with a memory containing a lookup table for matchingportions of the merge codes with respective logic ports of the accessstage associated with the access modules to which the correspondingmerge requests are to be sent.
 11. The device as claimed in claim 1,wherein at least one of the access modules comprises a library of staticpages from which are extracted at least in part tagged data pagesdelivered to the multiplexing stage in response to page requests,without exchange with the associated dedicated server.